fix(#2528): sync VALID_ROLES with Go's ValidRoles() - #6369

HIGH — Secrets layer now keys secret/variable names off derived agent names; Go keys them off roles

secrets.ts is documented as a read-only port of SecretsLayer.Analyze (internal/layers/secrets.go), but this PR changes the value fed into secretNameForRole/variableNameForRole from agent.role to agent.name, where name is now the derived agent name (explicit name:, or the basename of source:).

Verified on this head, Go always names these credentials from the role:

• internal/layers/secrets.go:123/134 call secretName(agent.Role) / variableName(agent.Role); secretName is FULLSEND_%s_APP_PRIVATE_KEY of strings.ToUpper(role) (secrets.go:183-188).
• Every construction of layers.AgentCredentials iterates a role list — internal/cli/admin.go:1434 (for _, role := range roles), internal/cli/admin.go:2025 (for _, role := range config.DefaultAgentRoles() in runAnalyze, the exact path this TS mirrors), internal/cli/github.go:658, and toAgentCredentials(role, ...) at admin.go:2284.
• AgentEntry.DerivedName() is used only for the harness registry, dispatch matching, poll, and fullsend agent listing (harness/registry.go:50, cli/run.go:3799, cli/poll.go:238, config/interfaces.go:240) — never for a secret or variable name (grep APP_PRIVATE_KEY under internal/ returns only role-based constructions).

Concrete regression: for the config in this PR's own new test (source: https://example.com/coder.yaml#sha256=… + name: my-coder), the UI now queries FULLSEND_MY-CODER_APP_PRIVATE_KEY (confirmed by running the shipped helpers). GitHub Actions secret names cannot contain hyphens, so that secret can never exist and the layer permanently reports not_installed/degraded for any org registering a custom agent — while the real FULLSEND_CODER_* credentials go unchecked. analyzeOrg.ts:13 was updated to assert the wrong contract in prose too ("Agent names from org config (drives secret/variable names)").

Note: the separate false-green when a config has no agents: key at all (config.NewOrgConfig never emits one, so agentsFromConfig returns [] and the layer reports "installed" having checked nothing) is pre-existing, but this PR re-commits to that source of truth in a rewritten function and doc comment.

Suggestion: Feed the secrets layer from roles, matching Go's analyze path — pass roles: string[] (from cfg.defaults.roles, falling back to Go's config.DefaultAgentRoles() set when absent, which is what runAnalyze uses) instead of agents: {name}[], and restore the analyzeOrg.ts:13 comment to say roles drive secret/variable names, citing internal/layers/secrets.go secretName/variableName. Keep agentsFromConfig/derived names only for callers that genuinely need agent identity. Add a test asserting a config with defaults.roles and no agents: key still checks FULLSEND_<ROLE>_APP_PRIVATE_KEY for every role.

HIGH — New test asserts a config Go rejects twice is valid; all agent validation dropped while the doc comment still claims Go parity

The new test "accepts agents with source-based entries" asserts validateOrgConfig(cfg) === null for a fixture containing - source: https://example.com/coder.yaml#sha256=abc123. Verified against ValidateAgentEntries on this head (internal/config/config.go:436-443):

• urlutil.ParseIntegrityHash requires a 64-hex sha256, so abc123 yields hasHash=false → agents[1] (my-coder): URL source must include a valid #sha256=<64-hex-char> integrity fragment.
• Even with a valid digest, the fixture has no allowed_remote_resources, so example.com fails MatchingAllowedPrefixInList → URL %q is not covered by allowed_remote_resources.

So the PR whose stated purpose is UI/Go parity ships a test hardcoding a UI/Go divergence, and the fixture will mislead the next person who treats it as a valid-config example.

More broadly, validateOrgConfig (line 132) still carries the doc comment "matches Go Validate errors" while performing zero agent validation. Go's Validate calls ValidateAgentEntries, which enforces: source required on enabled entries (config.go:410), explicit name on disabled entries (config.go:407), derived name against ^[a-zA-Z0-9][a-zA-Z0-9_-]*$ (config.go:415), case-insensitive duplicate names (config.go:420-426), https-only sources, no http://, no other :// schemes, no absolute paths, no .. traversal (config.go:444-460).

Sub-point: a legacy - role: triage entry now passes the TS shape checks and derives name "" (confirmed by running the helpers), where Go's AgentEntry.UnmarshalYAML fails at parse time with "agents entry uses legacy role/name/slug format (removed by ADR 0045 Phase 4)" — i.e. the stale-format config this migration targets is exactly the one the UI stops reporting.

Suggestion: Fix the fixture to a real 64-hex #sha256= digest under an allowed_remote_resources-covered prefix (or flip the assertion to the expected Go error string), and port the checked subset of ValidateAgentEntries into validateOrgConfig: require source on enabled entries, an explicit name on disabled entries, ^[a-zA-Z0-9][a-zA-Z0-9_-]*$ on derived names, https-only with a valid integrity fragment plus allowlist match, reject http://, other schemes, absolute paths, backslashes and .., and detect case-insensitive duplicates. Add negative tests mirroring each Go error string, including the legacy - role: entry. If a narrower scope is intended, at minimum narrow the validateOrgConfig doc comment to state which Go validations are and are not ported.

MEDIUM — Removed typeof guard lets a non-string agents[].name escape as a raw TypeError on the org row

This PR deletes the only type assertion on agent fields (agents[${i}].role must be a string) and replaces it with if (typeof el === "string") continue;, validating nothing inside mappings (orgConfigParse.ts:112-118).

Reproduced by running the shipped helpers in Node: a YAML name: 42 parses to a number under the core schema, derivedAgentName returns it unchanged (if (entry.name) return entry.name; — line 163 does not check the type), agentsFromConfig returns [{name: 42}] without throwing, and the throw only happens later in secretNameForRole (secrets.ts:6): TypeError: r.toUpperCase is not a function. That throw originates inside analyzeSecretsLayer, which runs at orgListRow.ts:104 — outside the inner try/catch whose comment deliberately degrades gracefully ("invalid YAML — still analyze other layers with empty agents/repos", orgListRow.ts:100) — so it lands in the generic outer catch at orgListRow.ts:133-137 and the whole org row renders a raw JS internal message instead of degrading.

For accuracy: the neighbouring case of a non-string source does not have this problem — source: 123 throws inside sourceBaseName during agentsFromConfig at orgListRow.ts:89, which is inside the inner try, so it degrades correctly. Only the name path escapes.

Related: a quoted enabled: "false" is !== false, so isAgentEnabled keeps the agent enabled with no type check.

Suggestion: In assertOrgConfigShape, assert name and source are strings when present and enabled is a boolean when present, using the same agents[${i}].<field> must be a … message style as the check that was removed.

MEDIUM — sourceBaseName does not mirror Go's DerivedName() as its doc comment claims

agentsFromConfig is documented as mirroring config.OrgConfig.Agents, and sourceBaseName hand-reimplements Go's AgentEntry.DerivedName() (internal/config/config.go:74-85, path.Base + strings.TrimSuffix(base, path.Ext(base))). Running both implementations side by side on the same inputs, they disagree:

The dotIdx > 0 guard is what breaks dot-leading basenames, and split("/").pop() is what breaks trailing slashes where path.Base strips them. (For an empty source Go returns "", not "." — path.Ext(".") == ".".)

This matters because the derived name is now the secret-lookup key (see the HIGH finding on secrets.ts), and this PR drops the derived-name regex check Go applies at config.go:415, so a divergent name reaches the GitHub API instead of failing validation. The existing [input-validation] note on this function states the TS implementation "mirrors Go's DerivedName() by design" — the runs above disprove that specific claim.

Suggestion: Strip trailing / before taking the last segment and mirror path.Ext for dot-leading basenames (no dotIdx > 0 special case), then add Go's ^[a-zA-Z0-9][a-zA-Z0-9_-]*$ check on the derived name so remaining malformed cases fail validation instead of producing a lookup key. Add unit tests for harness/, harness/triage.yaml/, .yaml and "" pinning the Go-matching values.